The use of Session Initiation Protocol (SIP) signalling is widespread in a variety of communications systems and architectures. One example is the IP Multimedia Subsystem (IMS) architecture developed under the Third Generation Project Partnership (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
The IMS uses Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Initiation Protocol is a text-based protocol specified by the Internet Engineering Task Force (IETF) in RFC 3261, similar to Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. Extensions to SIP are also specified in several other IETF specifications.
SIP makes it possible for a calling party to establish a packet switched session to a called party (using so-called SIP User Agents (UA) installed in the User Equipment (UE)) even though the calling party does not know the current IP address of the called party prior to initiating the call. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. As shown in FIG. 1a control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user equipment, UE, accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network, IP-CAN. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer 4. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality.
A SIP proxy, such as a CSCF, is defined in RFC 3261 as an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity “closer” to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.”
RFC 3261 describes an OPTIONS method that can be used to query the capabilities of another party such as another user device or a proxy server. This allows a SIP client to discover information about the supported capabilities, methods, content types, extensions, codecs etc. of the other party. This can be done without “ringing” the other party. The response, containing details of the supported capabilities, is returned in a SIP 200 OK message.
It is becoming more common for a user to have access to a network using one (or more) of a variety of devices. For example, Bob might connect to an IMS network (or other network that uses SIP) using any of a mobile device, a personal computer, a fixed line telephone and a set top box. When Alice wishes to ‘ping’ Bob to ascertain his device capabilities, by sending a SIP OPTIONS message, the SIP OPTIONS is sent to each of Bob's devices. When Alice receives a SIP 200 OK message from the device that is quickest to respond, the capabilities contained in the SIP 200 OK message are the capabilities that Alice registers. Subsequent SIP 200 OK messages that are received from Bob's other devices are discarded.
A problem with the signalling described above is that the response to the querying party (Alice) only reflects the capabilities of the device that is fastest to respond. The capabilities of Bob's other devices will not be known to Alice, as the subsequently received SIP 200 OK responses are discarded. Alice therefore does not have a complete knowledge of the capabilities of Bob's various devices. If, for example, Bob owns an audio device and a messaging device, and the audio-device is the fastest to respond to the SIP OPTIONS message, Alice's device will believe that Bob's device is capable of audio only, when in fact Bob also has a registered device that is capable of messaging. Alice might therefore choose not send Bob a messaging communication.